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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

Please note that the present document is a revision to TR 102 542 [i.3], and has been converted to a TS because the 
language used in the document is akin to that of a TS. 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1 21 8 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 5 of a multi-part deliverable covering the GuideUnes for the implementation of 
DVB-IPTV Phase 1 specifications, as identified below: 

Part 1 : "Core IPTV Functions" ; 

Part 2: "Broadband Content Guide (BCG) and Content on Demand"; 

Part 3: "Error Recovery"; 

Part 4: "Remote Management and Firmware Update"; 

Part 5: "Content Download Service (CDS)". 
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Scope 



The present document is designed as a companion document to help implement the DVB-IPTV Phase 1 version 4: 
Transport of MPEG2-TS Based DVB Services over IP Based Networks [1], which is referred to as the DVB-IPTV 
Handbook. The present document is organized as part of a multipart document on Guidelines for the implementation of 
DVB-IPTV Phase 1 specifications. 

The present document deals with Content Download Service. Content Download Services describe the functionality to 
download content items to the local storage of the HNED. The consumption is independent of the delivery. 

The present document describes: 

• an architectural overview how Content Download Services may be deployed; 

• some use cases in the scope of Content Download Services; 

• a summary of the system reference architecture and the system components; 

• deployment examples for use cases based on CDS specification. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 034 (Vl.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based 

DVB Services over IP Based Networks". 

[2] ETSI TS 101 154 (Vl.8.1): "Digital Video Broadcasting (DVB); Specification for the use of Video 

and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream". 

[3] ETSI TS 102 539 (Vl.2.1): "Digital Video Broadcasting (DVB); Carnage of Broadband Content 

Guide (BCG) information over Internet Protocol (IP)". 

[4] ETSI TS 102 822: "Broadcast and On-line Services: Search, select, and rightful use of content on 

personal storage systems ("TV- Anytime")". 

[5] ETSI TS 102 822-3-1 (Vl.3.1): "Broadcast and On-line Services: Search, select, and rightful use 

of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 1: Phase 1 - 
Metadata schemas". 

[6] IETF RFC 5053: "Raptor Forward Error Correction Scheme for Object Delivery". 

[7] ETSI TS 102 833: "Digital Video Broadcasting (DVB); File Format Specification for the Storage 

and Playback of DVB Services". 

[8] ETSI TS 102 824: "Digital Video Broadcasting (DVB); Remote Management and Firmwai-e 

Update System for DVB IPTV Services (Phase 2)". 
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[9] BBF TR-069 (December 2007): CPE WAN Management Protocol vl.l, Issue 1 Amendment 2. 

[10] BBF TR-106 (November 2008): "Data Model Template for TR-069-Enabled Devices", Issue 1, 

Amendment 2. 

[11] BBF TR-157 (March 2009): "Component Objects for CWMP". 

[12] BBF TR-135 (December 2007): "Data Model for a TR-069-enabled STB". 

[13] BBF TR-140 (December 2007): "TR-069 Data Model for Storage Service Enabled Devices", 

Issue 1.1. 

[14] W3C (May 2000): "Simple Object Access Protocol (SOAP) Version 1.1". 

[15] IETF RFC 2818: "HTTP Over TLS". 

[16] IETF RFC 3926: "FLUTE - File Delivery over Unidirectional Transport". 

[17] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[18] ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime 

information in DVB transport streams". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] DVB BlueBook A145: "Digital Video Broadcasting (DVB): Internet TV Content Delivery Study 

Mission Report". 

[i.2] Proceedings of ACM SIGCOMM 2002: "Wave and Equation Based Rate Control using Multicast 

Round-trip Time", M. Luby, V. Goyal, S. Skaria, and G. Horn,Pittsburgh PA, August 2002. 

[i.3] ETSI TR 102 542: "Digital Video Broadcasting (DVB); GuideHnes for DVB IP Phase 1 

Handbook". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in TS 102 034 [1] apply: 

CDS HNED storage: storage on the HNED dedicated to Content Download Services of a single service provider 

component: specific set of functionalities 

NOTE: It can offer this functionality to other components in the same device. 

connecting component: component which is used to connect link layer components with each other 

Content Download Service (CDS): service that provides download delivery of content items to the local storage of the 
HNED. The consumption is independent of the delivery 

content item: editorially coherent grouping of one or more audiovisual or generic data files which are intended to be 
consumed in conjunction with each other 

content provider: entity that owns or is licensed to sell content or content assets 

Content on Demand (CoD): program provided at the request of the end user for direct consumption (real-time 
streaming) 
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Content Service Provider (CSP): entity which acquires/licenses content from Content Providers and packages this 
into a service 

Download Session Description: collection of parameters that describe how a content item can be downloaded within a 
download session using the DVB-IPTV Content Download Service 

DVB-IPTV service: one or more programmes under the control of a service provider delivered over IP. The 
programmes can be made available either as part of a schedule or on demand 

NOTE: The programmes can be made available for direct consumption (Live Media Broadcast or Content on 
Demand services) or for local storage and later consumption (Content Download services). 

Home Network End Device (HNED): device that is connected to a home network and which typically terminates the 
IP based information flow (sender or receiver side) 

pull download service: content download initiated by the user 

push download service: content download initiated by the service provider without explicit request by the user 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

A/V AudioA^ideo 

BBF BroadBand Forum 

BCG Broadband Content Guide 

BiM Binary MPEG Format for XML 

CDN Content Delivery Network 

CDS Content Download Service 

CoD Content on Demand 

CPCM Content Protection and Copy Management 

CPE Customer-Premises Equipment 

CRID Content Referencing IDentifier 

CSP Content Service Provider 

CWMP CPE WAN Management Protocol 

DM Data Model 

DSL Digital Subscriber Line 

DVB Digital Video Broadcasting 

DVBSTP DVB SD&S Transport Protocol 

EEC Forward Error Correction 

FLUTE File Delivery over Unidirectional Transport 

HD High Definition 

HDD Hard-Disk Drive 

HNED Home Network End Device 

HTTP Hyper Text Transfer Protocol 

HTTPS Hyper Text Transfer Protocol Secure 

IP Internet Protocol 

IPTV Internet Protocol Television 

MPEG Moving Picture Experts Group 

P2P Peer-to-Peer 

PVR Personal Video Recorder 

RFC Request For Comments 

RMS Remote Management System 

RPC Remote Procedure Call 

SAP Session Announcement Protocol 

SD Standard Definition 

SDP Session Decription Protocol 

SSL Secure Socket Layer 

STB Set-Top Box 

TS Transport Stream 

TVA TV Anytime 

UDP User Datagram Protocol 
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URI 

WAN 
XML 



Uniform Resource Identifier 
Wide Area Network 
extensible Markup Language 



Overview 



The aim of the DVB-IPTV content download system is to enable delivery of IPTV Content on Demand services to a 
local storage on the HNED in a non real-time manner over broadband IP channels where the data rate may be variable 
and even intermittent. The services target downloading of AA'^ content, including pure audio content, and associated 
metadata. 

Figure 1 shows a possible CDS service environment. The involved parties in CDS services are the content provider, the 
IPTV CDS service provider and the IPTV CDS user. This clause is dedicated to translate typical service offerings 
provided by the CDS service provider to the CDS user into the technical specification in [1], clause 12, specifically the 
CDS system Network Functions, the CDS HNED functions, as well as the normative interfaces CDS-x. The application 
of the specification in [1] is not restricted to the provided use cases. 
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Figure 1 : CDS Service Environment 

The CDS service provider obtains content and content rights from a content provider through content provision 
interface (XI). The CDS user communicates with the CDS service provider to consume the content through interface 
X2 that may for example be a portal or some other user interface offered from the CDS service operator to the CDS 
user. XI and X2 are outside the scope of the present document. 

The CDS user interacts with the CDS HNED function through an X4. For example, the HNED may present some 
available BCG information into some human-readable format and the CDS user selects content items to be downloaded. 
Interface X4 is also not within the scope of the present specification. Also not specified in here is the communication 
between the CDS service provider and the CDS network functions through interface X3. 

However, in order to appropriately describe typical service operations, high-level semantics of these interfaces and the 
messages exchanged on these interfaces are introduced. The specification only addresses the CDS service 
announcement, delivery request, delivery, and delivery completion reporting. More specifically, the specification only 
targets services delivered over operator-managed networks, i.e. the service provider controls delivery of the stream, 
quality of service, integrity and security of the content and management of the local storage. 

Nevertheless, for the operation of a CDS service, the following processes are essential but are out of the scope of the 
present document: 

• Service Offering: A generic process by which the CDS service provider offers a CDS service to the CDS user. 

• Service Subscription: A process that is used by the CDS user to subscribe to the entire service offering or parts 
of the service offering of a CDS service provider 

• Content Provisioning: A process, by which the content provider provides individual content items or a bundle 
of content items to the CDS service provider. 
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Content Offering: A process, by which the service provider offers individual content items or a bundle of 
content items to the CDS user. 

Content Item Selection: A process by which the CDS user selects a specific content item for download from 
the content offering. 

Content Item Delivery Notification: A notification from the CDS network functions to the service provider on 
the successful delivery of the content item. 

Content Item Availability Notification: A notification of the CDS HNED function to the CDS user on the 
availability of a new content item. 

Content Item Consumption Request: A request of the CDS user for the consumption of a content item. 

Content Item Authorization: An optional process that authorizes the consumption of the content item for the 
CDS user. 

Content Item Consumption: A process during which the CDS user consumes an authorized content item. 

The scenarios and informative message flows provided in clause 5 of the present document use these informative 
messages to address aspects, which are not covered by the specification in [1]. Some services and applications are not in 
the scope of the specification in [1], clause 12, for example downloading of content to network storage, downloading of 
applications and downloading of software updates are out of scope. 



5 Use Cases for Content Download Services 

The following use cases are only examples. They are not intended to be exhaustive. In all use cases, usage rules should 
be aligned with DVB-CPCM, where practical. 

5.1 Use case 1 : Pull download 

An IPTV customer requests download of a content item (e.g. movie) in advance: 

Customers would be informed about the content available via a BCG, for example defined in TS 102 539 [3] 
by using the OnDemandProgramType with DeliveryMode attribute set to "download". 

They would select the content that they want and the timing, pricing, AN format (SD, HD) of its delivery, etc. 

Ordering in advance reduces demand at peak periods and might therefore be offered at lower cost 

The download system would check that there is local capacity available and reserve it 

Customers would check (via the UI) that the title had been delivered and view it according to agreed usage 
rules. 

In a pull download service scenario the CDS user having subscribed to a CDS service offering requests download of a 
content item in advance. In this case the user is informed about the availability of the content items for download via the 
BCG and selects the content item for consumption. The CDS system may optimize the delivery by for example taking 
into account user preferences or the current system load. Once the content item is successfully delivered and available 
on the HNED, the CDS user is informed that the content item had been delivered and may select consuming it 
according to agreed usage rules. 

Figure 2 shows a possible realization of a pull download service scenario. Within the scope of the specification is the 
CDS service announcement for pull download service delivery: The CDS content item is announced for availability as 
pull content and the delivery session parameters are provided in the CDS service announcement. The CDS delivery 
itself includes acquisition request for the content item, content item delivery, and reception reporting of the present 
document. By the announcement of the content item as pull content, the CDS HNED function can appropriately notify 
the content availability to the CDS user. 
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Figure 2: Pull Download Service Scenario 



5.2 Use case 2: Pull Download with Early Playout 

An IPTV customer requests download of a content item (e.g. movie) for immediate delivery. 

Customers would be informed about the content available via a BCG. 

They would select the content that they want and the pricing, A/V format (SD, HD) of its delivery, etc. 

The content is downloaded to the local storage (the download may be made at low bitrate). 

The customer is informed that the viewing can be launched (depending on the size of the content and the 
bitrate of the delivery). 

The customer can view the content before the complete end of the download. 

It is left to the implementer to cope with early-termination conditions such as the user trying to use trick modes 
to access content that has not been fully downloaded yet, or if the download should not complete for any 
reason. 

In a slightly modified operation mode, the CDS user requests the download of a content item for immediate 
consumption during download. The content is progressively downloaded to the local storage, potentially at a different 
bit rate (lower, higher, variable) than the media stream rate. The HNED CDS function decides at what time the viewing 
is launched taking into account content item metadata and delivery information. The decision for the time of play out is 
not in the scope of the present document. However, CDS HNED function should ensure that once the content item play 
out has started, the play out is not interrupted. It is also not in the scope of the present document to cope with early- 
termination conditions such as the user trying to use trick modes to access content that has not been fully downloaded 
yet, or if the download should not complete for any reason. The CDS HNED should be provisioned for such cases. 

The CDS network function may prohibit the progressive download feature, for example as the network function knows 
ahead of time that it will reduce the bit rate at later time during the delivery session or as the delivery is expected to be 
intermittent, such that the CDS HNED function can not predict from the initial delivery at what time fluent play out can 
be guaranteed. 
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Figure 3 shows a possible realization of a progressive download scenario. The scope of the present document is again 
on CDS service announcement and CDS delivery. In the announcement, the content item is marked as being available 
as pull content with progressive download support. After user selection the CDS HNED function starts the download 
and is permitted to launch the play out at an appropriate time during the download without further user request. 
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Figure 3: Progressive Download Scenario: Pull Download Service with Play out 
before complete reception of content item 



5.3 



Use case 3: Push download 



One or more content items are downloaded to a user's local storage by an operator in anticipation of the customers 
needs (e.g. movies, video clips for a barker channel, etc.): 

• The operator may predict the customers requirements based on a profile (for those that agree). 

• A number of titles would be downloaded to the users local storage when the broadband connection is not in 
use or when it is lightly used (users to agree on scenarios and allocate the necessary capacity in advance). 

• The user would be informed via the UI that one or more content items are now available for consumption 
according to the agreed usage rules. 

• The user accepts one content item for consumption and is billed according to any of a number of possible 
charging schemes. 

• Bulk discounts might be offered or there may be discounts for allowing adverts to be inserted. 

In a push download service scenario environment one or more content items are downloaded to the local storage by the 
service provider in anticipation of the CDS user's need or based on some service subscription agreement. The content 
item in this case is offered in the BCG as push download service content item and automatically downloaded by the 
CDS HNED function. The content item is offered to the CDS user for play out only after it is entirely delivered to the 
CDS HNED function. Once the user accepts a content item for consumption, the CDS system may authorize the content 
and then consumption is permitted from the local storage. 

Figure 4 shows a possible realization of a push download service scenario. The scope of the present document is on 
CDS announcement and CDS delivery. In the announcement, the content item is marked as push download service 
content. This allows the CDS HNED function to appropriately advertise the content to the CDS user. The content is not 
offered for consumption before it is available entirely on the CDS HNED function. 
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Figure 4: Push Download Service Scenario 



5.4 Use case 4: CDS-based Peer-to-Peer Delivery 

Considering the huge amount of available audio- visual content, the provisioning of a large number of on-demand media 
servers for service operators may be costly. On the Open Internet, peer-to-peer (p2p) distribution architectures have 
gained significant importance due to the cost-efficient provisioning of large-size file distribution [i.l]. The CDS 
specification enables the use of such peer-to-peer architectures. For this purpose, it is necessary that one content item 
can be downloaded from multiple servers in parallel. It is up to the CDS service operator to distribute the content across 
the multiple servers and to announce the availability of the content to the receiving functions. 

The CDS service operator may choose to distribute the content items on multiple servers in its domain or may use a 
content delivery network (CDN). The operator may also provide server functionality on several or all CDS HNEDs, 
such that the HNEDs itself can serve the content items to other HNEDs resulting in a classical peer-to-peer delivery 
under operator control. Hybrid CDN-p2p solutions may be considered as well to address short-coming of p2p in 
asymmetric DSL environments [i.l]. 

It should be noted that peer-to-peer delivery is not a dedicated use case as such. It can be applied to pull and push 
service modes as a variation of the normal unicast delivery from a single server. It promises load balancing by 
appropriate distribution of the download sessions. Another alternative is multicast delivery in case content items have to 
be provided to a large number of CDS HNEDs in parallel. Clause 10.5 in [1], discusses the different delivery methods 
in detail. 



System Reference Architecture and System 
Components 



6.1 



General 



To support Content Download Services, TS 102 034 [1] specifies: 

• a functional architecture to identify the normative interfaces from the network to the HNED to support CDS; 

• an announcement and metadata structure based on TV Anytime and the Broadband Content Guide (BCG); 

• Content Delivery functions to support scalable and reliable delivery of content items; 

• Local and Remote Storage Management for the CDS HNED function; 
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• the supported content item formats; 

• secure transport means. 

The different components of the CDS specification in TS 102 034 [1] are briefly summarized in this clause. 

6.2 Reference Architecture 

To enable efficient content download services in IPTV deployments, several functions are introduced in the network 
and end devices. The functions ensure proper operation of the service, including service discovery, reliable and efficient 
delivery of content items as well as management of the content items on the local HNED storage. Figure 5 shows the 
DVB-IPTV CDS architecture. A brief explanation of the individual functional components is provided in the following. 

The CDS management controls all other CDS functions. The CDS network content storage function stores and prepares 
the content items for delivery to the HNEDs. The CDS Service Announcement function advertises the availability of 
content items in pull or push download service mode as well as the corresponding download session parameters. The 
CDS announcement is based on the Broadband Content Guide (BCG) [3] as well as download session descriptions. 
More details are provided in clause 6.3. 

The actual download functions are decomposed into multicast download functions, unicast download functions and 
reception reporting. Multicast download components enable reliable distribution of content items to a group of 
receivers simultaneously. They include the multicast download component, which is based on the File Delivery over 
Unidirectional Transport (FLUTE) [16] protocol, the file repair and completion polling components. Completion polling 
is used by the CDS network function to determine if all HNEDs participating in the multicast download have completed 
the reception of the content item in order to be able to terminate the multicast download. Furthermore, file repair 
enables the repair of incomplete files after the multicast download session has been terminated. 

The unicast download functional components aim at reliably distributing content items to individual HNED's upon their 
request. The unicast download is based on the Hyper Text Transfer Protocol (HTTP) [17]. The redirection management 
component permits redirecting unicast download requests to alternative download sources such as a single alternative 
server, a multicast session on which the requested content is available or a list of multiple servers each of which 
providing a different portion of the requested content item (peer-to-peer approach). 

After a successful download of file chunks, files or content items the HNED may inform the CDS management via the 
reception reporting function about the successful download. This offers the possibility for the CDS management to 
collect statistics about the content download activity, adapt the download strategy dynamically and initiate billing for 
the downloaded content items. Local storage management allows the CDS management to manage CDS local storage 
and content on the HNED. 

The network and corresponding HNED functions communicate through specific interfaces that are highlighted in 
Figure 5 (CDS-1 to CDS-8). The protocols that are used on the individual interface are mostly standard Internet 
protocols such as HTTP and FLUTE. 
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Figure 5: Content Download System Functional Architecture 



6.3 



CDS Announcement and Metadata Structure 



6.3.1 Overview 

The CDS Announcement functions provide the CDS HNED functions with information about content items that are 
offered by the CDS service provider in push and pull download service modes to the CDS HNED. Service 
announcement includes metadata for the content items, its availability for download and download session descriptions 
providing details on how and where to access the files of the content item. The CDS Announcement information is 
delivered over CDS-1 using unicast and multicast based protocols. 

6.3.2 Content Guide and Metadata Information for CDS 

DVB uses the Broadband Content Guide (BCG) as defined in TS 102 539 [3] for the announcement of Content on 
Demand (CoD) and Scheduled Content services. The BCG is based on TV Anytime (TV A) metadata as defined in [4]. 
For the support of CDS, TV Anytime and the BCG have been extended to allow the announcement of content items 
available via this new service. 
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The TVA instance description OnDemandProgramType, originally defined to support streaming Content on Demand 
services, is extended to support CDS Pull download services. This includes an indicator for streaming or download 
delivery, an early playout flag and expiration times for the content item. The same information can also be provided by 
the Extended On-Demand Binary Locator in case Content Reference Identifier (CRID) resolution is performed. 
Information about the content item (e.g. title, director, actors) itself is provided by the Content Description Metadata 
(see TS 102 822-3-1 [5]). A content item available as CDS Pull download is announced in the same way as a streaming 
Content on Demand item. Only by the additional information in the OnDemandProgramType they are differentiated. 

For the purpose of setting up a push download service a new Instance Description type is defined within TVA, the 
PushDownloadType. This new type informs the HNED about the availability of a content item for push download. CDS 
HNEDs that have subscribed to the push download service autonomously download content items announced through 
this PushDownloadType without informing the user on the download activity. After the successful download the 
content item can be announced via the BCG as a normal streaming Content on Demand item, but with the content 
located on the CDS storage of the HNED instead of on a network server. This metadata for the announcement of the 
content item to the user (Content and Instance Description Metadata) can be provided either via normal BCG delivery 
mechanisms or it can be delivered to the HNED as part of the download itself. 



6.3.3 Download Session Descriptions 



A reliable download of content items to a local storage requires several parameters such as server locations or FLUTE 
session and reception reporting information. This information is not part of the BCG metadata as the BCG is dedicated 
to content item related information, but not to delivery information. Delivery information is provided in dedicated 
download session descriptions. A download session description contains all relevant information for a reliable 
download of a content item. Download session descriptions may be described in extended Markup Language (XML) or 
Session Description Protocol (SDP) syntax. 

Unicast and multicast delivery of download session descriptions is supported. HTTP is used for unicast delivery of 
XML or SDP-based download session descriptions. The DVB Service Description & Selection transport protocol 
(DVBSTP) [1], clause 5.4.1, permits the multicast distribution of XML-based download session descriptions and the 
Session Announcement Protocol (SAP) does the same for SDP-based download session descriptions. Download session 
descriptions are referenced from the CDS -specific BCG instance description metadata or binary locator via a URI 
scheme which indicates the transport protocol and provides additional parameters to locate the specific download 
session description for the content item. 

The download session consists of multiple parameters that initialize the content item delivery functions of the CDS 
architecture. The parameters are categorized into: 



• 



• 



General session parameter providing session ID and version, content item format, download timing 
information and download session type. 

Reception Reporting parameters providing the HNED with information on reception reporting for content 
items or smaller components of content items such as individual files or even chunks (byte ranges) of files. 

• Unicast download parameters for each file of the content item, including a unique reference, content-type, 
length, file digest. As files may be downloaded in individual chunks from one or multiple servers, parts of this 
information may be provided for each chunk. Furthermore, the URI to the servers on which the files are 
available, need to be provided. Not each server may necessarily host the entire file, but only chunks of it. 

• Multicast download parameters include a file reference for each file of the content item, FLUTE Transport 
Session Identifier (TSI), IP source addresses. Forward Error Correction (EEC) encoding IDs for No Code or 
Raptor [6], number of FLUTE channels with IP multicast address, port number and maximum bandwidth for 
each FLUTE channel. 

• Completion polling parameters, namely IP address and port numbers to which CDS HNED function shall send 
completion poll responses. 

• File repair parameters, namely for each file recovery server the server URI, the recovery mode as well as some 
load balancing information to avoid scalability issues. 

For the different download session modes defined in clause 6.4.3 different parameter sets are valid and have to be 
provided accordingly. 
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6.4 Content Items - Definition and Delivery 

6.4.1 Definition 

The reliable delivery of content items is the major functionality of a content download system. Reliable download is 
needed in order to provide error free content to the user for a good user experience. Furthermore flexible delivery 
mechanisms need to be supported in order to handle the various use case, network topologies and content demands. 
This clause introduces the content item formats and the download mechanisms. 

Content items form the basic entities that are downloaded and consumed within CDS. A content item may consist of 
one or more files. These can be video, audio, combined video and audio and related metadata files. A content item can 
be viewed as an editorially coherent grouping of one or more audiovisual or generic data files that are intended to be 
consumed in conjunction. A content item can simply be one file, which contains audiovisual information in a 
synchronized manner. However, a content item may also be quite complex and may contain several individual media 
files that are rendered according to a scene description. In addition, a content item may also have associated metadata 
with content and instance description information. 

6.4.2 Formats 

CDS differentiates between content item formats and file formats. The content item format defines the structure of the 
individual files of the content item and provides hints to the HNED on how to handle the playout of the content item. 
For example if the content item consists of a single media file, a media file with associated metadata or a more complex 
structure. 

While a download session could handle any type of file, CDS is supporting only specific file formats that can be 
handled by the HNED for playout to the user. For media files the MPEG-2 Transport Stream (TS) [2] has to be 
supported as this format is also used for the DVB IPTV streaming Content on Demand and Linear TV services [1]. 
Metadata has to be in BCG XML format as either uncompressed textual file or as Binary MPEG format for XML 
(BiM). Optional also the DVB File Format [7] can be supported. The DVB File Format allows encapsulating media 
streams and associated metadata into a single file. 

6.4.3 Delivery 
6.4.3.1 Overview 

A major aspect of CDS is obviously the delivery of content items from the CDS network storage to the CDS HNED 
storage. Delivery needs to be provided in a reliable and efficient manner. As already discussed, content items are 
downloaded in sessions that are described by download session descriptions. CDS supports the download of all files 
associated with a content item as part of a single download session. 

Different types of download sessions are defined: 

• Scheduled Multicast Download Session 

• Carousel Multicast Download Session 

• Unicast Download Session 

In support of the pull and push download service modes, the CDS delivery system may choose one of the above 
download session modes. Note that whilst the push download service mode might most often be realized using a 
multicast download session and the pull service mode might most often be realized by a unicast download session, other 
combinations are also possible according to service provider requirements. For example, a push download service to a 
small population of HNEDs can make use of a unicast download session and a pull download service for popular 
content items that are expected to be downloaded by a large number of users can make use of a carousel multicast 
download session. Worthwhile to note that by the use of unicast file repair for a multicast session or multicast 
redirection of a unicast download session, the download mode may change during a session. 

A download session is completed if all files of the content item as defined by the download session description have 
been completely downloaded. The different components of the content item delivery are introduced in more details in 
the following. 
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6.4.3.2 Multicast delivery 



Multicast download modes provide download of content items to multiple HNEDs using IP multicast based on FLUTE 
as defined in RFC 3926 [16]. They are therefore suitable for efficient download of the same content items to many 
receivers. 

As multicast delivery is based on the User Datagram Protocol (UDP), which does not provide any error recovery 
mechanisms, additional mechanisms like Forward Error Correction (EEC), repetitive transmission and unicast file repair 
are introduced to provide a reliable download. 

Multicast download may be provided in a scheduled mode or a carousel mode. In scheduled mode a multicast session is 
explicitly scheduled by the network to begin at a specific start time. The CDS system expects that the HNEDs join the 
session at the appointed time. The service provider continues the session until all HNEDs that have joined the session 
have received all the files of the content item. The service provider can make use of a completion polling functionaUty 
to identify if HNEDs are still joined to the multicast session and downloading the content item. 

In carousel mode, a multicast session is scheduled to be available over a long period of time and HNEDs basically have 
the option to join and leave the sessions at any time. Such a mode may be very suitable if a content item is to be 
provided in the background, for example over 24 hours or even several days. HNEDs may download the content in a 
pure best effort manner. The files of the content item are sent continuously during the session. Figure 6 shows the 
concept of a simple carousel, for which the original file data is repeated. In case of losses, the reception of the file might 
take a long time, as the HNED has to wait until the missing data is again delivered by the carousel. In contrast, when 
using forward error correction based on a fountain code, such as Raptor codes [6], each packet is different and useful for 
the receiver and the download can be completed in a much shorter time frame. 
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Figure 6: Carousel Mode with repetition and fountain FEC 

Another interesting feature for efficient multicast delivery is the provisioning of a multicast rate adaptation scheme. By 
the provisioning of multiple FLUTE channels, the HNED can measure the observed bandwidth on the link and can 
subscribe to an appropriate number of FLUTE channels such that the available access bandwidth is fully exploited. 
Some suitable algorithms for efficient multicast rate adaptation are for example provided in [i.2]. 

In case the CDS HNED cannot complete the download of the content item during the time the multicast session is 
active, CDS provides file repair mechanisms. In this case the receivers that were not able to complete the download, can 
request missing data from repair servers. The repair server may send missing FLUTE symbols, or they may just use the 
unicast download functionalities and send the missing byte ranges of the incomplete files. 

6.4.3.3 Unicast delivery 

The Unicast content download mode provides download of content items using IP unicast based on HTTP as defined in 
RFC 2616 [17]. By the flexibility of the system, the individual files of a content item may either be downloaded from a 
single server or from multiple servers. HTTP download sessions for a file can be redirected to a single server or 
multiple server locations with an optional retry delay and also a redirection to a multicast download session is 
supported. This allows the CDS management to adapt its download strategy to the user demands and avoid overload 
conditions. For example a multicast session can be dynamically established if a large group of users requests the 
download of a content item within the same time window and the unicast download requests of these users can be 
redirected to the multicast session. 
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The CDS can even request the HNEDs to perform download of a single file from multiple server locations in parallel. 
Files are split in chunks of equal size (except for the last chunk of the file) and distributed over multiple server 
locations. The availability of the chunks on the different servers is provided to the HNEDs by the download session 
description. The HNED can randomly select the server in case a chunk is available on several servers. For download of 
the complete file all individual chunks have to be downloaded, which can be done in parallel. A digest of each chunk 
and of the complete file is provided in the download session description in order to verify that the chunks are correctly 
received and that the file is correctly reconstructed from the chunks. With reception reporting the successful reception 
of chunks and files can be reported to the CDS management. 

It is worth to mention that the DVB CDS specification does not make any assumptions on the location or topology of 
the various servers. Therefore, servers may be network-based or may reside on HNEDs for peer-to-peer delivery. 
Parallel download is not only limited to the multiple server file download as described above. A HNED can also start 
parallel downloads of several content items with the same or different download session modes. Only the available 
bandwidth and processing resources of the HNED will set the limits. 

6.4.3.4 Reception Reporting 

Reception reporting is an essential component for reliable distribution. It can be used for billing and charging purposes, 
but it also provides the possibility to monitor the availability of content items, files and file chunks in the CDS system. 
Reception reporting is carried out by providing dedicated reception reporting servers. The CDS HNED determines if the 
item(s) for which reporting is requested (e.g. content item, file, chunk) are successfully downloaded and sends the 
XML-coded reception reporting reports to a reception reporting server. The reception reporting server may again be 
chosen randomly from the list of reception reporting servers and back-off timing may be used to ensure scalability. 

6.4.4 Handling of Content Items stored on HNEDs 

The management of the content items stored on the HNED is essential, as in general the storage capacity on such 
devices is restricted for cost-efficient service deployments. Worthwhile to note that for example an MPEG-2 encoded 
SDTV content (MPEG-2 TS stream at 4 MBit/s) requires roughly 1,8 GByte of storage per hour and a H.264 encoded 
HDTV content (MPEG-2 TS stream at 10 MBit/s) requires roughly 4,5 GByte of storage per hour. Therefore, only a 
limited amount of content items can be stored on the HNED. Furthermore, there might also be a contention for the 
available capacity between the user (storage for pull service and personal video recorder) and the service operator 
(storage for push service). The physical storage on the HNED may have to be shared among these different service 
types. In any case it is essential that before downloading a new content item, the HNED verifies that sufficient space on 
the CDS HNED storage is available by comparing the file size provided by the content metadata with the available 
storage space. In case the CDS HNED storage space is not sufficient the download cannot be performed. Content items 
which are expired as defined by their expiry time parameter can be automatically deleted from the CDS HNED storage 
in order to make room for new downloads. The CDS management can use the reception reporting functionality to keep 
track about the availability of content items on HNEDs. Beyond this, an advanced CDS local storage and content item 
management system has been defined by DVB as part of the DVB Remote Management System specification [8] such 
that the CDS network functions can directly control, manage and delete the content items on the CDS HNED storage. 
Details on this advanced CDS local storage and content item management system are provided in clause 6.5. 

Content item management and deletion only refers to actions for the content item on the CDS HNED storage. For 
example, any content item that is moved outside the CDS HNED storage - even if it was acquired through CDS - is 
outside the control of the CDS operator. The permission to move the content item from the CDS HNED storage to a 
private storage on the HNED or even to a different device is typically handled by a content protection system. CDS as 
such is transparent to any content protection systems. 

6.5 Storage Management 
6.5.1 Introduction 

DVB-IPTV CDS provides only limited content management functionality by the use of the reception reporting and 
expiry time parameter. However, in particular for Push Download use cases a service provider wants to have more 
control over the content items stored on the CDS HNED and over the CDS HNED storage space available for CDS. But 
also in case of Pull Download such additional functions are of interest for example to provide Help Desk support in case 
the user complains about missing storage space which prevents him from downloading new content items. DVB has 
therefore extended its Remote Management System (RMS) specification [8] to support CDS local storage and content 
item management. 
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Although the DVB-IPTV RMS specification [8] is basically RMS neutral and may eventually support more than one 
RMS, it currently specifies and recommends only extensions for a Broadband Forum (BBF) CPE WAN Management 
Protocol (CWMP) based solution. The BBF CWMP framework includes the definition of the protocol in TR-069 [9] 
and the associated Data Models (DMs) in TR-106 [10] (generic data model), TR-157 [11] (component objects), 
TR-135 [12] (STB data model), TR-140 [13] (storage service device data model), and others. In order to support CDS 
local storage and content item management, extensions to TR-135 [12] are specified in DVB. 

Before discussing those management extensions we introduce how storage management might be implemented in a 
CDS HNED. In most cases the HNED vendor will already provide a partition on the HNEDs hard disk drive (HDD) for 
the storage of content. Content includes the recordings of a personal video recorder (PVR), as well as CDS Push and 
Pull content. There may be additional non-video content that is stored on the same HDD partition, e.g. photos, music, 
etc. In order to independently manage the storage space for each of those services there are basically two options: 

1) Separate folders are used for the storage spaces of the services and the maximum capacity of the folders are 
managed using folder quotas. Quota management is inherently supported with most operating systems or can 
be added as a separate software package. 

2) The quota management of the storage spaces is emulated by the HNED software. 

Both options allow limiting the storage space that is available for each of the services (PVR, CDS Push and Pull) 
ensuring that not just one service consumes the complete storage space. 

6.5.2 CDS Local Storage and Content Item Management Extensions for 
RMS 

The DVB-IPTV RMS extensions for CDS provide the following functionalities: 

• Query the entire CDS Push and Pull service storage spaces. 

• Modify the entire CDS Push and Pull service storage spaces 

• Query the used CDS Push and Pull service storage spaces. 

• Query the list of content items stored on the CDS Push and Pull service storage spaces. 

• Delete individual content items on the CDS Push and Pull service storage space. 

The management of the CDS Pull storage space and content items requires permission from the end user. This 
permission can be provided via the user interface of the HNED on request (e.g. help desk access to the HNED) or is part 
of the end-user's service level agreement with the service provider. 

6.5.3 TR-1 35 data model extensions 

The TR-135 data model [12] including the DVB extensions for CDS local storage and content item management 
(orange colored objects) is shown in Figure 7. Certain parameters as well as certain sub-objects that are not relevant for 
CDS are not shown in the figure. 
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Figure 7: TR-135 data model with extensions for CDS 

The TR-135 [12] data model contains a Capabilities object where the HNED specifies its capabilities for various 
functions. The information provided is therefore read-only and depends on the hardware and software functions 
supported by the HNED. DVB has defined new X_DVB_CDSPush and X_DVB_CDS_PULL objects each with a 
CDSPushCapable and CDSPullCapable parameter, respectively, to indicate the support for CDS Push and Pull storage 
and content item management. These extensions are specified by DVB and hence, the X_DVB_ prefix is used to 
indicate a vendor specific extension from the Broadband Forum's point of view. 

The functional objects and parameters to manage the CDS Push and Pull storage and content items are modeled inside 
the TR-135 Components objects [12]. These are the new DVB specific objects X_DVB_CDSPush and 
X_DVB_CDSPull. Both objects are identical except that the X_DVB_CDSPull object includes the additional 
OperatorManageEnable parameter that is set by the HNED when the end user gives the permission that the service 
provider can manage the CDS Pull service. In case the user does not provide the permission, the HNED will not reveal 
the X_DVB_CDSPull object via CWMP. 

The Reference parameter in those objects points to a TR-140 [13] which represents the HNED storage space for the 
CDS Push or Pull service. The Storage Service instance can either be a Physical Volume, a Logical Volume, or a Folder 
within a Logical Volume. As mentioned earlier it is recommended that HNED vendors implement the storage space for 
CDS Push and Pull as separate folders. Only in this case it is possible to configure the storage space using the Quota 
object via CWMP. The Physical Volume and Logical Volume objects are not resizable at least from a CWMP 
perspective and therefore do not support Quota objects. 
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The content items available on the CDS Push or Pull storage space are represented by the Content object. This object 
contains the number of content items (ItemNumberOfEntries) and for each content item (Content.Item.{i}) the content 
reference identifier (ContentReferenceld) and version number (VersionNumber) as parameters. The content reference 
identifier is the TVA CRID [11] of the content item as provided in the BCG CDS announcements. 

The service provider can get the list of content items via the Content object and can delete individual content items by 
deleting the instance of the Content.Item object representing the specific content item. Note that all files associated with 
the content item are deleted. 

6.5.4 CWMP transactions for CDS 



6.5.4.1 



Overview 



CWMP use a Remote Procedure Call (RPC) method for the remote management transactions between the RMS server 
and the HNED. The RPC is encoded in SOAP [14] and transferred via HTTPS [15]. Transaction sessions are always 
initiated from the HNED to the RMS server. In case the RMS server wants to establish a session with a HNED it has to 
send a Connection Request to the HNED to trigger a session initiation by the HNED as shown in Figure 8. Hereafter the 
HNED opens a SSL connection and sends an HTTP POST carrying an Inform request that in turn is responded by the 
RMS server with an Inform response. The Inform request provides information to uniquely identify the HNED, the 
reason for the session initiation and data model specific parameters. One or more CWMP request/response cycles wiU 
follow during a transaction session in which the RMS server requests some actions from the HNED or vice versa. 



HNED 



RMS server 



Transaction session setup request 



Session initialization 



CWMP request/response 




Session closure 



Figure 8: Basic CWIVIP transaction session 

In the following clauses some examples of CWMP request /response cycles for CDS local storage and content item 
management are shown. 

6.5.4.2 Query of the overall CDS Push service storage space 

Figure 9 shows the transaction sequence for a query of the overall CDS Push service storage space. 
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In a first step the RMS server retrieves the full hierarchical name of the actual TR-140 [13] Storage Service instance or 
an object within this instance which represents the storage space of the CDS Push service. The Reference parameter of 
the CDS Push object (X_DVB_PUSH. Reference) is used in the GetParameterValues RPC request as the reference to 
the storage object. The name of the storage object is returned in the response to the request ([Storage]). Afterwards the 
RMS server issues a GetParameterValues RPC for the capacity parameter of this storage object 
("Storage". Quota.Capacity) that returns the overall storage space available for that object. 
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GetParameterValue [Storage]. Quota.Capacity 



GetParameterValueResponse [Storage capacity] 



Figure 9: Query CDS Push storage space transaction 



6.5.4.3 



Deletion of a CDS Pull service content item 



In order to delete a content item the RMS server first has to retrieve the instance i of the content item object 
(Content. Item. I i I) which represents that content item. For that the RMS server queries the HNED for the list of CDS 
Pull content items with a GetParameterValue RPC for the CDS Pull service object as shown in Figure 10. 

The RMS server compares the content reference identifier parameter of the returned content item objects with the 
identifier of the content item that shall be deleted. If a match occurs for one of the content item object instances the 
RMS server issues a DeleteObject RPC request for this specific object instance. 
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Figure 10: Deletion of a CDS Pull service content item 



Deployments Examples for Use Cases using CDS 



7.1 



Introduction 



In this clause the mapping of some use cases to the CDS specification is provided. However, note that the system is 
obviously not restricted to the provided use cases, and has different deployment options to address additional use cases. 



7.2 



Pull Download Service Scenario 



The use of the D VB-IPTV CDS technology for the purpose of user initiated pull download is shown in Figure 1 1 . The 
BCG Content Description Metadata provides a description of the content item to the HNED that is presented to the CDS 
user. From the Instance Description Metadata or binary locator the HNED receives the information that the content item 
is provided in pull download service mode. This information is also presented to the user as he may have to wait for the 
download completion until the content item can be played out. The user requests the download of the content item and 
the HNED acquires the download session description for this specific content item from the URI provided by the BCG. 
At the advertised time the HNED will start the download. Typically, the download will be a unicast delivery, but the 
content item may in certain cases also be distributed using multicast. Once the content item is available on the HNED, 
the user is notified and can initiate the consumption of the content item. Any further consumption request of the user 
will be immediately performed as long as the content item is available on the CDS HNED storage. The content item 
may have an expiry time assigned to it such that all the files of the content item are removed from the CDS HNED 
storage after the time has elapsed. 
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Figure 11: User-Initiated Pull Download 



Push Download Service Scenario 



The use of the DVB-IPTV CDS technology for the purpose of operator-initiated push download is shown in Figure 12. 
In this case the BCG provides a PushDownloadType Instance description that triggers the HNED to access the 
download session description and initiates the download of the content item at the advertised time. Once the content 
item has been downloaded to the CDS HNED Storage, the content may be advertised to the user by providing content 
description metadata and instance description metadata or a binary locator with a content URI pointing to the content 
item on the CDS HNED storage. These metadata can be provided by a BCG update or as part of the download itself. 
Again the content item may have an expiry time assigned to it to remove all files from the CDS HNED storage after the 
time has elapsed. 




Figure 12: Operator-Initiated Push Download 
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7.4 Peer-to-peer Download Scenario 

The CDS specification enables a content delivery mode based on multiple network unicast servers (see clause "10.6.3.3 
Multiple Server Unicast Download" in TS 102 034 [1]). In this clause a note indicates that "...nothing in the multiple 
server unicast download procedures makes any assumptions about the location or topology of the various servers. For 
example, servers may be network-based or may reside on HNEDs to support advanced distributed media delivery. . . ". 
So this clause aims at describing how to implement an advanced distributed media delivery such as peer-to-peer (p2p) 
in CDS. 

Peer-to-peer (P2P) can be considered as an alternative or an extension to a multiple network unicast servers download 
paradigm. So enabling p2p in CDS does not mean that it replaces the multicast or unicast delivery paradigms but just 
completes them. Moreover knowing that the "multiple unicast servers download" procedure can be used in the CDS file 
repair procedure (see clause "10.6.2.6 File repair Procedure" in TS 102 034 [1]), P2P-based delivery could also be 
applied in CDS file repair. 

The p2p delivery considered in this section of the CDS guidelines is based on a centralized hybrid CDN-p2p paradigm 
which means that the downloads of the content are decentralized (HNED to HNED-based or HNED to server-based) 
while the control of the information regarding content location is centralized (HNED to server-based). In this case CDS 
with p2p delivery is based on reference use cases implementing multiple servers redirection as defined in clause 
" 10.6.3.4.2 Multiple Server redirection" in TS 102 034 [1], but where the multiple "servers" used to upload parts of a 
content file (byte range(s) or chunk(s)) can be replaced by other "HNEDs". 

It is worth noting that CDS with p2p delivery respects all CDS interfaces as defined in clause 10.2 "Figure 17: Content 
Download System Functional Architecture" in TS 102 034 [1] and does not define any extension to these interfaces. In 
CDS p2p delivery the network side "Unicast Delivery Function" is used as a redirection server answering to the 
requesting HNED with a list of servers and HNED (peers) able to upload the requested content, these last ones being 
selected from information provided by the network side "Reception Reporting function" which plays the role of a p2p 
indexing server. Moreover the CDS HNED function side which already supports HTTP/1.1 client functions shall also 
implement at least a subset of HTTP/1.1 server functions to support CDS p2p exchange. This subset of functions shall 
be the same as the ones supported by a network unicast server capable to upload a content file or a part of it (byte 
range(s)) and is described in clause "10.6.3.3 Multiple server unicast download" in TS 102 034 [1]. On the other side to 
simplify such a centralized hybrid CDN-p2p architecture, the redirection functions do not need to be supported by the 
HTTP server implemented in the HNED. 

In practical terms when an HNED requests a content to the network side "Unicast Delivery Function", this function 
responds by a "Multiple server redirection" message as described in clause "10.6.3.4.2 Multiple server redirection" in 
TS 102 034 [1]. This message is built from the reception reporting data linked to the requesting content. In particular 
the "Client-ID" field of the reception reporting messages which is described in clause "10.6.5.3 Table 28: Reception 
reporting message" in TS 102 034 [1] can be used to identify a server in the "Server-Base-URI" fields of "Multiple 
server redirection" message described in clause 10.5.4, "Table 26: Mapping of Download session Parameters to 
Download sessions Modes" - Unicast Download Related Parameters part). 



£75/ 



26 



ETSI TS 102 542-5 V1.3.1 (2011-09) 



History 



Document history 


VI. 1.1 


November 2006 


Publication as TR 102 542 


Vl.2.1 


April 2008 


Publication as TS 102 542 


VI. 3.1 


September 2011 


Publication 















£75/ 



